Unfortunately, the default limits are defined in src/webgpu/capability_info.ts which is listed as off limits to navigator_gpu.ts. I tried moving the limits table to src/common/limits.ts but then src/webgpu/capabilities_info.ts complained that src/common/limits.ts is off limits. So, I'm not sure where I can put a shared limits.ts file that both navigator_gpu.ts and capabilities_info.ts can access.

I think src/common/util/limits.ts would be allowed. I don't remember the rule syntax, but the message seems to imply that:

              {
                "target": "./src/webgpu",
                "from": "./src/common",
                "except": ["./framework", "./util"],
                "message": "Non-framework common/ code imported from webgpu/ suite"
              },

So I wrote this change before the update to the limits to add maxXXXInYYYStage. With those added this code broke because it would request limits that don't exist.

So, I made it so it makes a temp device. This might be fine but, tests that test low-power vs high-performance may have issues. I'd either have to always request a temp adapter and temp device OR, I'd have to turn the requestAdapter descriptor into a key to cache the limits. Can that wait or later or should I do something now?

This is fine, though I don't quite understand why it's needed. In requestAdapter, after having already called origRequestAdapterFn, we already have the list of supported limits.

I'm not sure what you're saying is not needed. An actual adapter will always have max limits. We create a device with no requiredLimits to get the default limits. We then create an adapter and set all adapter.limits to the defaults so down stream it won't see the max limits. There are tests that check things throw if we request higher than max. These tests will fail to throw if we don't manually enforce that the max is the default (not the actual max). That's why we need the defaults.

I'm not sure what you're saying is not needed. An actual adapter will always have max limits. We create a device with no requiredLimits to get the default limits. We then create an adapter and set all adapter.limits to the defaults so down stream it won't see the max limits. There are tests that check things throw if we request higher than max. These tests will fail to throw if we don't manually enforce that the max is the default (not the actual max). That's why we need the defaults.

Sorry, I mean I'm not sure why a temp device is needed. We know the default value for each limit from our info tables (as long as we know which featureLevel to use). From any adapter we can see which limits are supported by the browser (by whether they exist in adapter.limits). So in the shim for adapter.limits we can return only the limit names that the original adapter had, with the values reduced to the defaults.

Though I'm not sure if what I'm saying makes sense because I haven't tried it.

That makes sense. I can put up a new PR to use the limits table.

another thing we could do is just set all the max limits to 0 since the impl is supposed to set them to the default. For min limits though, some have restrictions like power-of-2 so I guess we'd still need the table.